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ABSTRACT 


The design of a LISP interpreter that allows tail-recursive procedures to be 
interpreted iteratively is presented at the machine-language level. 
Iterative interpretation means that, without any program transformations, no 
environments and continuations will be stacked unless necessary. 


We apply a specific modification within a traditional stack~oriented version 
of LISP interpreter, without any non—recursive control structure. The design 
is compatible with value-cells as well as a-lists LISP processors. 


We present a complete modified interpreter written itself in LISP and an 
informal proof that it meets its requirements. 
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nod 


1.0 INTRODUCTION 


It is well-known that tail~recursive procedures (TR for short) are formally 
equivalent to iterative procedures [1]. Unfortunately, when interpreted, 

TR code behaves a3 ordinary recursive code, and we do not obtain the benefit 
of the formal equivalence. We need a way to make the formal equivalence also 
a practical one. 


The problem of the computation of TR procedures can be stated in terms of 
program transformations, or in terms of interpreters specially designed to 
handle them properly. 


Static program transformations (4,10] from TR to iterative programs are mainly 
used on compiler-oriented LISP systems, and therefore do not allow full access 
to interpreter-oriented tools of debugging, breaks, traces etc. Moreover, as 
they are name~sensitive, they cannot handle procedures with circular types. 


Interpreter~oriented processing of TR procedures uses non-recursive control 
structures like message-passing as in Hewitt's ACTORS system(7,8 | or generalized 
FUNARG devices with static a-lists, as in Sussman's SCHEME [12]. Also delayed 
evaluation of CONS 6] has been proposed in which partial building of a struc- 
ture is triggered by invocations to the decomposition primitives CAR and CDR 
applied to this virtual structure. 

As interesting as they are, there do not seem to be any evident ways to adapt 
such methods to ordinary recursive stack-oriented LISP interpreters. 


In contrast, we propose a simple way to process TR procedures iteratively, 
without any program transformations or non-recursive control structures. Our 


scheme can be used with a~lists as well as value-cells stack-oriented LISP 
interpreters. 


2.0 TAIL RECURSIVE SCHEMATA 


In (i, a TR schema in iterative form is defined as a recursion equation 
f(xl,...,xn) = a(f,xl,...,xn,hl,...,hm) 

where g is a conditional expression defining £ in terms of the functions 

hl,...,hm; g is said to be iterative if £ occurs exactly in terms of g in 

the form THEN £(...) or ELSE f(...). 

For example, this is the recursive form of the well-known program for 


addition (NOTE 1) 


(de plus (x y) (if (= x 0) y 
(add] (plus (sub! x) y)))) 


and this is the corresponding iterative form 


(de plus (x y) (if (= x 0) y 
(plus (subl x) (addl y)))) 


NOTE | : (if c el e2... en) is the LISP equivalent to the form 
tf e then el else e2; ... 3 en fz. 
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We must generalize the previous definition of iterative schema to any named 
\-expression such that 


(1) £ = ¢ A (xl...xn) ses (£ al...an)) (NOTE 2) 
i.e. the last term of the A-expression body is a call of this A-expression. 


DD £ = ¢ A(el...kn) «ee GEe (f al...an) ...)) 
and 
£= ( \€xl...xn) ... (if c el e2 ... (E al...an))) 


i.e. the THEN-part or the last term of the ELSE-part of an if-form is ‘a call 
of this A-expression. 


Nested if~forms are valid under this schema, e.g. 


Í 


tt 


( A(x.. xn) «2 (i£ ct (if c2 ... (if cm (E£ al..-an) ce.) «++))) 


(3) £ ( A(xl...xn) ... (cond ... (c el ... em-} (Ë al...an)) ..-)) 


H 


Note that the condition c, even if it consists solely of the constant T, must 
be mentionned explicitely, in contrast with for example INTERLISP [13] style 
of writing CONDs. 


3.0 RETURN CONTINUATIONS 


We notice that these schemata share a common property: all of them are instances 
of forms interpreted by the LISP system internal Function PROGN. 


These forms will be interpreted recursively if PROGN is defined as follows. 

Let us suppose the variable EXP is the name of a register which contains the 
form to be evaluated and the result after the evaluation. TEMP is a working 
register, SAVE and RESTORE push and pop respectively their argument onto a4 
stack, REC pushes a return continuation (NOTE 3), and UNREC restores the current 
continuation from the stack. 


PROGN = temp+exp; 
while not (null (temp)) 
do save(temp); exp+car(temp); 
rec EVAL; temp+restore(); 
temp+cdr (temp) 
od 


unrec()$ 


NOTE 2: This part of the definition means that we allow non-terminating 
procedures. 


NOTE 3: Here we use the continuation concept [it] the same way as in f9], where 
a continuation is just a list of instructions to be executed. 
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On the contrary no return continuation will be stacked at an instance of a 


TR call of our iterative A-expressions if PROGN is designed as: 


PROGN = whtle not (null(cdr(exp))) 
do save(exp); exp+car(temp) ; 
rec EVAL; exptrestore(); 
exptcdr (exp) 
od 
exptcar (exp); jumpTo EVAL; 


The last clause of a PROGN argument (a list of expressions to be evaluated) 
will be passed directly to EVAL, which obtains the definitive control of the 


continuation. 


If LISP TR procedures had no arguments, the interpreter would automatically 


handle calls of forms like 
f= (AQ) Gif c el e2... en-] (£))) 
as 


while not c do eval(e2)3 5 eval(en-1) od; 
eval(el); 


Then the program writer could design its procedures in the most natura 


l way, 


without paying attention to what are necessary or unnecessary recursions [14 . 
But, as LISP procedures generally use argument passing, we need a way to omit 
unnecessary saving of environments (NOTE 4) by the internal LISP system function 


APPLY, in the case of TR procedures. 


4.0 THE HANDLING OF ENVIRONMENTS 


A redundant environment is defined as a new environment caused by the call of 
a TR procedure, the old environment being unnecessarily saved, in spite of the 


fact that it will be never used again. 


To avoid redundant environments, we have to modify APPLY in the following 


manner. 


When APPLY has discovered that it must handle a \~expression, first it examines 
the stack at a definite place to see if the same \~expression has been called 
before. If this is the case, it does not save the current environment onto the 
stack, and just binds every variable of its formal arguments list to tts value, 
then gives the body of the \-expression to PROGN. If this is not the case, 


t 


then APPLY saves the current environment (which means that the \-expression is 
called for the first time, as far as APPLY can see) onto the stack, then saves 
the list which represents the A-expression being called, then builds a new 
environment as before, and finally saves a return continuation to a part of 


APPLY which restores environments. The control is then given to PROGN. 


http:/Awww.artinfo-musinfo.org Tail-Recursive Procedures in LISP, September 1976, page 5 / 14 


The definite element which APPLY examines is then the next-to-last item saved 

in the stack. . 

This part of APPLY can be designed in the following manner (the field CVAL being 
the value~cell of LISP variables) : 


PART~OF-APPLY = tf car(exp)=\ then 
if STACK[TOP-1] =exp then 

for~each x in cadr(exp) do 
x.CVAL«car(arglist); 
arglist+cdr(arglist) 
od 

exp+cddr (exp); jumpTo PROGN 

else 

save(sentinel); 

for-each x in cadr(exp) do 
save(x.CVAL); save(x)3 
x.CVAL+car(arglist) ; 
arglist«cdr(arglist) 
od 

save(exp); exp+cddr(exp); rec PROGN; 

restore(); 

whtle sTACK{ TOP] 4 sentinel do 

xerestore(); 
x. EVAL+restore() 
od 


restore(); unrec() 


ment is meant an association of variables with values. 

n take the form of a-lists, where the 
value of every variable is found (with the possibility of multiple 
instances of the same variable), or can take the form of value-celils, 
in which case the value associated with the variable is unique and 
immediately accessible, old associations being saved on the stack. 


NOTE 4: By environ 
In LISP, saved environments ca 
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5.0 EXAMPLES OF TR~PROCEDURES 


Here are some examples to illustrate programming in TR style, with the 
modified interpreter. 


(1) An iterative Ackermann function : 


(de ack (x y) (axy nil)) 


(de a (x y p) (cond 
((= x 0) (if p (a (car p) (addi y) (cdr p)) 
(addi y))) 
((= y 0) (a (sub! x) 1 p)) 
(T (a x (subl y) (cons (sub! x) p))))) 


(2) Building a list of factorials : 
(de factlist (n) (gn 1 (list 1))) 
{de g (n x r) 
GE (=xn)r 
(g n (addi x) 
(cons (times (addi x) (car r)) r)))) 


(3) Building a factorial procedure with circular type + 


(setga g (O (x y f) 
(if (>= x0) y 
((car £) (subl x) (times x y) £))))) 
to obtain factorial n we call ((car g) nlg) 
Our modified interpreter appears to be tname~insensitive" and can 
run this example iteratively, which cannot be handled by program 
transformations, 
(4) Notice that forms like 


CO (x) (x x)) 1A (x) (x x))) 


being run iteratively do not cause overflow of the stack. 
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6.0 THE MODIFIED INTERPRETER 


Here is the complete modified LISP interpreter (NOTE 5). It is written 
itself in LISP in the machine language style of Sussman's SCHEME [12]. 
We uge a global environment and we do not use any recursive features. 


(de run () (setq pe 'toplevel) (Loop)) 
(de loop () (while t (apply pe ntt))) 


We use a non-terminating control loop which runs the "next" procedure, 

in which the non-modified LISP internal function apply is called over and 
over again. The variable pe plays the role of a program counter. 

Here is the top-level loop : 


(de toplevel () (setq link nil stack ntl) (save ‘topl) 
(setq exp (read) pe ‘eval)) 


(de topl () (print exp) (setq pe 'toplevel)) 
Here are the "pipe-lined" procedures eval, evlis and apply : 


(de eval () (eond 
((numberp exp) (unrec)) 
(latom exp) (setq exp (car exp)) (unrec)) 
(T (setq hdexp (car exp) exp (cdr exp) pe 'evall)))) 


(de evall () (cond 
((listp hdexp) (save hdexp) (setq pe 'evlts)) 
(lor (get hdexp ‘expr) (get hdexp ‘subr)) 
(save hdexp) (setq pe tevits)) 
((setq temp (get hdexp 'fexpr)) 
(setq arglist (List exp) exp temp pe ‘apply)) 
((get hdexp 'fsubr) (setq pe hdexp)) 
(T (setq hdexp (car hdexp))))) 


(de evlis () (setq built nil pe ‘evlisi)) 


(de evlis1 () (tf (null exp) f 
(setq arglist (reverse built) exp (restore) pe ‘apply! 
(save exp) (save built) (save tevlis2) 
(setq exp (car exp) pe 'eval)}) 


(de evlis2 () 
(setq butlt (cons exp (restore)) exp (edr (restore)) pe 'evltsi)) 


NOTE 5 : This interpreter is in fact a simplification of the one running 
under the name of VLISP at the University of Vincennes 2,5 | on 


a PDP 10 and a T1600 computer. 
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(de apply () (cond 
((atom exp) (eond 
((setq temp (or (get exp l'expr) (get exp 'fexpr))) 
(setq exp temp)? 
(for (get exp 'subr) (get exp *fsubr)} 
(setq pe exp)) 
(T (setq exp (car exp))))) 
((or (eq (car exp) (setq temp Ue, 
(eq (car exp) (setq temp ’y))) 
(setq \-y~eup exp) 
(if (eq temp 'y) (setq arglist (car argitst))) 
(if (eq (cadre stack) A~y~exp) 
(rebind (cadr \-y-exp) arglist) 
(bind (cadr \-y~exp) argltst) (save h-y-exp) (save ‘apply3)) 
(setq exp (eddy r~y-exp) pe tprogn) } 
(T (save arglist) (save 'apply2) (setq pe ‘eval)))) 


A form (y(xl...xn) el e2 ... en) is like a A-expression but when applied 
to an argument which is a list, it distributes the elements of this list 
over the formal arguments xl..-.xn . This is very efficient for handling 
multiple values recursive procedures. 

(de apply2 () (setą arglist (restore) pe tapply)) 

(de apply3 () (restore) (unbind) (unrec)) 

The internal procedure unbind restores old environments, yebtnd simply 


builds a new environment without saving the current one in contrast to 
bind which saves the old environment. 


Next we come to the “sequencer” procedure progn : 
(de progn () (tf (edr exp) ntl (save exp) (save 'progn1)) 
(setq exp (car exp) pe teval)? 


(de progni () (setq exp (cdr (restore)) pe 'progn)) 


Finally, as an illustration of control procedure of FSUBR type, we give the 
code for tf : 


(df if () (save exp) (save 'ifl) (setq exp (car exp) pe teval)? 


(de tf1 () (tf exp (setq exp (cadr (restore)) pe 'eval) 
(setq exp (eddr (restore)) pe 'progn))) 
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~Q- B. 


7.0 CHECKING-RULES 


We must now devise a means of insuring that our interpreter meets its 
requirements. We shall use "ehecking-rules" of the form 


51{P1}P2:S2 


where $1 is the state of the stack when entering procedure Pl, 82 is the state 

of the stack when leaving procedure Pl, and P2 is the name of the next procedure 
to enter. When P2 is the label ‘retcont" it means that Pl has no next procedure 
to enter, so a recursive return to the head of the stack has to be performed. 


Examination of the interpreter yields the following rules, which constitute 
in a sense an abstract version of the interpreter, the enter and exit states of 
the stack playing the role of an history [3]. 


afeval}retcont:ay evallia 


afevall}evlis:hdexpia y applyta v fsubria vevallia 


hdexp:a{evlissevlisl:hdexpia 
ndexp:afevlisl}eval:evlis2:builtiexpthdexp:ay applyto 
built:exp:hdexp:a{evlis2}evlis|:hdexpia 
afapplyltapply:ay subr:ay fsubria 


Vv progniav progn: apply3:A~y-exp:oldbindings?a 
Veval:apply2:arglistia 


arglist:a{apply2}apply:a 
\-y-exp:oldbindings:ulapply3}retcontia 
Bi progn}eval:prognl:exp:B yeval:8 

exp: 8{prognl}progn: B 
B{if}eval:ifl:exp:8 (NOTE 6) 
exp:8{iflteval:8v progni6 


f 
Using the checking-rules, we can show that the interpreter handles TR programs 


correctly. 
let foo = (A (xl... xn) el... em) 
with em = (foo al ... an) 


First of all we must show that the state of the stack is the same when evaluating 
em and when entering progn with exp = (el... em). 


NOTE 6 : Recall that tf is of FSUBR type. 


http:/Awww.artinfo-musinfo.org Tail-Recursive Procedures in LISP, September 1976, page 10 / 14 


Fa i 
i l -10- 


A 


(el... em) with a{progn}. 


ut 


Let exp 


Suppose m = |, we have 

a{prognieval:a and therefore afeval}. 
If m> 1 we have 

a{progn}eval:progni:expia 


and if the evaluation of the head of exp does not enter into an infinite 
loop, we shall obtain 


exp:a{prognl }prognia 
2 followed by 
a{progn} , now with the length of exp being m-1 D. 


Further, we must show that when 
apply3:foo:oldbindings:a{eval} 


then exp = em, i.e. it is only when evaluating em that we can find foo 
as the next-to-top item in the stack. 


Suppose exp = ek with k #m. The state of the stack when entering eval 
will be 


progni:(ek ... em):8{eval} 


and (ek ... em) being a tail of foo cannot be equal to foo (A. 
Finally we must show that, if there is not an infinite loop when evaluating 
one of the ei , I < i <m, the old bindings will be restored. 
As before, if exp = em, with 
apply3: foo:oldbindings:a{eval} 
when eval returns, the state of the stack is 
foo:oldbindings:a{apply3}retcont:a 


and apply3 restores the environment immediately preceding the first call of 


foo 0. 
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8.0 CONCLUDING REMARKS 


We have proposed a LISP interpreter in which TR code behaves at run-time 
as efficiently as well-written iterative code, with the extra benefit of 
avoiding explicit side-effects as well as manual or automatic program 
transformations. 

Another advantage is that it is insensible to renaming, e.g. if we have 


(de foo (x) ... (foo (g x))) 
and we perform 
(put 'fie (get 'foo 'expr) ‘expr) 


then the call (fie a) will be interpreted exactly the same way as a call 
of foo. 


The modification we have proposed does not depend on particular implemen- 
tations of environments. This one more encouragement to write programs in 
recursive style, particularly since our modification can be applied very 
easily with no apparent drawbacks to any LISP interpreter. 
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